home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1191 < prev    next >
Text File  |  1995-07-25  |  47KB  |  1,084 lines

  1.  
  2.  
  3.  
  4.  
  5. Network Working Group                                           J. Mogul
  6. Request for Comments: 1191                                        DECWRL
  7. Obsoletes: RFC 1063                                           S. Deering
  8.                                                      Stanford University
  9.                                                            November 1990
  10.  
  11.                            Path MTU Discovery
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC specifies a protocol on the IAB Standards Track for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "IAB
  19.    Official Protocol Standards" for the standardization state and status
  20.    of this protocol.  Distribution of this memo is unlimited.
  21.  
  22.  
  23.                            Table of Contents
  24.  
  25.        Status of this Memo                                             1
  26.        Abstract                                                        2
  27.        Acknowledgements                                                2
  28.        1. Introduction                                                 2
  29.        2. Protocol overview                                            3
  30.        3. Host specification                                           4
  31.            3.1. TCP MSS Option                                         5
  32.        4. Router specification                                         6
  33.        5. Host processing of old-style messages                        7
  34.        6. Host implementation                                          8
  35.            6.1. Layering                                               9
  36.            6.2. Storing PMTU information                              10
  37.            6.3. Purging stale PMTU information                        11
  38.            6.4. TCP layer actions                                     13
  39.            6.5. Issues for other transport protocols                  14
  40.            6.6. Management interface                                  15
  41.        7. Likely values for Path MTUs                                 15
  42.            7.1. A better way to detect PMTU increases                 16
  43.        8. Security considerations                                     18
  44.        References                                                     18
  45.        Authors' Addresses                                             19
  46.  
  47.  
  48.                              List of Tables
  49.  
  50.        Table 7-1:   Common MTUs in the Internet                       17
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Mogul & Deering                                                 [page 1]
  58.  
  59.  
  60. RFC 1191                   Path MTU Discovery              November 1990
  61.  
  62.  
  63.  
  64.  
  65. Abstract
  66.  
  67.    This memo describes a technique for dynamically discovering the
  68.    maximum transmission unit (MTU) of an arbitrary internet path.  It
  69.    specifies a small change to the way routers generate one type of ICMP
  70.    message.  For a path that passes through a router that has not been
  71.    so changed, this technique might not discover the correct Path MTU,
  72.    but it will always choose a Path MTU as accurate as, and in many
  73.    cases more accurate than, the Path MTU that would be chosen by
  74.    current practice.
  75.  
  76.  
  77. Acknowledgements
  78.  
  79.    This proposal is a product of the IETF MTU Discovery Working Group.
  80.  
  81.    The mechanism proposed here was first suggested by Geof Cooper [2],
  82.    who in two short paragraphs set out all the basic ideas that took the
  83.    Working Group months to reinvent.
  84.  
  85.  
  86. 1. Introduction
  87.  
  88.    When one IP host has a large amount of data to send to another host,
  89.    the data is transmitted as a series of IP datagrams.  It is usually
  90.    preferable that these datagrams be of the largest size that does not
  91.    require fragmentation anywhere along the path from the source to the
  92.    destination.  (For the case against fragmentation, see [5].)  This
  93.    datagram size is referred to as the Path MTU (PMTU), and it is equal
  94.    to the minimum of the MTUs of each hop in the path.  A shortcoming of
  95.    the current Internet protocol suite is the lack of a standard
  96.    mechanism for a host to discover the PMTU of an arbitrary path.
  97.  
  98.           Note: The Path MTU is what in [1] is called the "Effective MTU
  99.           for sending" (EMTU_S).  A PMTU is associated with a path,
  100.           which is a particular combination of IP source and destination
  101.           address and perhaps a Type-of-service (TOS).
  102.  
  103.    The current practice [1] is to use the lesser of 576 and the
  104.    first-hop MTU as the PMTU for any destination that is not connected
  105.    to the same network or subnet as the source.  In many cases, this
  106.    results in the use of smaller datagrams than necessary, because many
  107.    paths have a PMTU greater than 576.  A host sending datagrams much
  108.    smaller than the Path MTU allows is wasting Internet resources and
  109.    probably getting suboptimal throughput.  Furthermore, current
  110.    practice does not prevent fragmentation in all cases, since there are
  111.    some paths whose PMTU is less than 576.
  112.  
  113.  
  114. Mogul & Deering                                                 [page 2]
  115.  
  116.  
  117. RFC 1191                   Path MTU Discovery              November 1990
  118.  
  119.  
  120.  
  121.  
  122.    It is expected that future routing protocols will be able to provide
  123.    accurate PMTU information within a routing area, although perhaps not
  124.    across multi-level routing hierarchies.  It is not clear how soon
  125.    that will be ubiquitously available, so for the next several years
  126.    the Internet needs a simple mechanism that discovers PMTUs without
  127.    wasting resources and that works before all hosts and routers are
  128.    modified.
  129.  
  130.  
  131. 2. Protocol overview
  132.  
  133.    In this memo, we describe a technique for using the Don't Fragment
  134.    (DF) bit in the IP header to dynamically discover the PMTU of a path.
  135.    The basic idea is that a source host initially assumes that the PMTU
  136.    of a path is the (known) MTU of its first hop, and sends all
  137.    datagrams on that path with the DF bit set.  If any of the datagrams
  138.    are too large to be forwarded without fragmentation by some router
  139.    along the path, that router will discard them and return ICMP
  140.    Destination Unreachable messages with a code meaning "fragmentation
  141.    needed and DF set" [7].  Upon receipt of such a message (henceforth
  142.    called a "Datagram Too Big" message), the source host reduces its
  143.    assumed PMTU for the path.
  144.  
  145.    The PMTU discovery process ends when the host's estimate of the PMTU
  146.    is low enough that its datagrams can be delivered without
  147.    fragmentation.  Or, the host may elect to end the discovery process
  148.    by ceasing to set the DF bit in the datagram headers; it may do so,
  149.    for example, because it is willing to have datagrams fragmented in
  150.    some circumstances.  Normally, the host continues to set DF in all
  151.    datagrams, so that if the route changes and the new PMTU is lower, it
  152.    will be discovered.
  153.  
  154.    Unfortunately, the Datagram Too Big message, as currently specified,
  155.    does not report the MTU of the hop for which the rejected datagram
  156.    was too big, so the source host cannot tell exactly how much to
  157.    reduce its assumed PMTU.  To remedy this, we propose that a currently
  158.    unused header field in the Datagram Too Big message be used to report
  159.    the MTU of the constricting hop.  This is the only change specified
  160.    for routers in support of PMTU Discovery.
  161.  
  162.    The PMTU of a path may change over time, due to changes in the
  163.    routing topology.  Reductions of the PMTU are detected by Datagram
  164.    Too Big messages, except on paths for which the host has stopped
  165.    setting the DF bit.  To detect increases in a path's PMTU, a host
  166.    periodically increases its assumed PMTU (and if it had stopped,
  167.    resumes setting the DF bit).  This will almost always result in
  168.    datagrams being discarded and Datagram Too Big messages being
  169.  
  170.  
  171. Mogul & Deering                                                 [page 3]
  172.  
  173.  
  174. RFC 1191                   Path MTU Discovery              November 1990
  175.  
  176.  
  177.  
  178.  
  179.    generated, because in most cases the PMTU of the path will not have
  180.    changed, so it should be done infrequently.
  181.  
  182.    Since this mechanism essentially guarantees that host will not
  183.    receive any fragments from a peer doing PMTU Discovery, it may aid in
  184.    interoperating with certain hosts that (improperly) are unable to
  185.    reassemble fragmented datagrams.
  186.  
  187.  
  188. 3. Host specification
  189.  
  190.    When a host receives a Datagram Too Big message, it MUST reduce its
  191.    estimate of the PMTU for the relevant path, based on the value of the
  192.    Next-Hop MTU field in the message (see section 4).  We do not specify
  193.    the precise behavior of a host in this circumstance, since different
  194.    applications may have different requirements, and since different
  195.    implementation architectures may favor different strategies.
  196.  
  197.    We do require that after receiving a Datagram Too Big message, a host
  198.    MUST attempt to avoid eliciting more such messages in the near
  199.    future.  The host may either reduce the size of the datagrams it is
  200.    sending along the path, or cease setting the Don't Fragment bit in
  201.    the headers of those datagrams.  Clearly, the former strategy may
  202.    continue to elicit Datagram Too Big messages for a while, but since
  203.    each of these messages (and the dropped datagrams they respond to)
  204.    consume Internet resources, the host MUST force the PMTU Discovery
  205.    process to converge.
  206.  
  207.    Hosts using PMTU Discovery MUST detect decreases in Path MTU as fast
  208.    as possible.  Hosts MAY detect increases in Path MTU, but because
  209.    doing so requires sending datagrams larger than the current estimated
  210.    PMTU, and because the likelihood is that the PMTU will not have
  211.    increased, this MUST be done at infrequent intervals.  An attempt to
  212.    detect an increase (by sending a datagram larger than the current
  213.    estimate) MUST NOT be done less than 5 minutes after a Datagram Too
  214.    Big message has been received for the given destination, or less than
  215.    1 minute after a previous, successful attempted increase.  We
  216.    recommend setting these timers at twice their minimum values (10
  217.    minutes and 2 minutes, respectively).
  218.  
  219.    Hosts MUST be able to deal with Datagram Too Big messages that do not
  220.    include the next-hop MTU, since it is not feasible to upgrade all the
  221.    routers in the Internet in any finite time.  A Datagram Too Big
  222.    message from an unmodified router can be recognized by the presence
  223.    of a zero in the (newly-defined) Next-Hop MTU field.  (This is
  224.    required by the ICMP specification [7], which says that "unused"
  225.    fields must be zero.)  In section 5, we discuss possible strategies
  226.  
  227.  
  228. Mogul & Deering                                                 [page 4]
  229.  
  230.  
  231. RFC 1191                   Path MTU Discovery              November 1990
  232.  
  233.  
  234.  
  235.  
  236.    for a host to follow in response to an old-style Datagram Too Big
  237.    message (one sent by an unmodified router).
  238.  
  239.    A host MUST never reduce its estimate of the Path MTU below 68
  240.    octets.
  241.  
  242.    A host MUST not increase its estimate of the Path MTU in response to
  243.    the contents of a Datagram Too Big message.  A message purporting to
  244.    announce an increase in the Path MTU might be a stale datagram that
  245.    has been floating around in the Internet, a false packet injected as
  246.    part of a denial-of-service attack, or the result of having multiple
  247.    paths to the destination.
  248.  
  249.  
  250. 3.1. TCP MSS Option
  251.  
  252.    A host doing PMTU Discovery must obey the rule that it not send IP
  253.    datagrams larger than 576 octets unless it has permission from the
  254.    receiver.  For TCP connections, this means that a host must not send
  255.    datagrams larger than 40 octets plus the Maximum Segment Size (MSS)
  256.    sent by its peer.
  257.  
  258.           Note: The TCP MSS is defined to be the relevant IP datagram
  259.           size minus 40 [9].  The default of 576 octets for the maximum
  260.           IP datagram size yields a default of 536 octets for the TCP
  261.           MSS.
  262.  
  263.    Section 4.2.2.6 of "Requirements for Internet Hosts -- Communication
  264.    Layers" [1] says:
  265.  
  266.           Some TCP implementations send an MSS option only if the
  267.           destination host is on a non-connected network.  However, in
  268.           general the TCP layer may not have the appropriate information
  269.           to make this decision, so it is preferable to leave to the IP
  270.           layer the task of determining a suitable MTU for the Internet
  271.           path.
  272.  
  273.    Actually, many TCP implementations always send an MSS option, but set
  274.    the value to 536 if the destination is non-local.  This behavior was
  275.    correct when the Internet was full of hosts that did not follow the
  276.    rule that datagrams larger than 576 octets should not be sent to
  277.    non-local destinations.  Now that most hosts do follow this rule, it
  278.    is unnecessary to limit the value in the TCP MSS option to 536 for
  279.    non-local peers.
  280.  
  281.    Moreover, doing this prevents PMTU Discovery from discovering PMTUs
  282.    larger than 576, so hosts SHOULD no longer lower the value they send
  283.  
  284.  
  285. Mogul & Deering                                                 [page 5]
  286.  
  287.  
  288. RFC 1191                   Path MTU Discovery              November 1990
  289.  
  290.  
  291.  
  292.  
  293.    in the MSS option.  The MSS option should be 40 octets less than the
  294.    size of the largest datagram the host is able to reassemble (MMS_R,
  295.    as defined in [1]); in many cases, this will be the architectural
  296.    limit of 65495 (65535 - 40) octets.  A host MAY send an MSS value
  297.    derived from the MTU of its connected network (the maximum MTU over
  298.    its connected networks, for a multi-homed host); this should not
  299.    cause problems for PMTU Discovery, and may dissuade a broken peer
  300.    from sending enormous datagrams.
  301.  
  302.           Note: At the moment, we see no reason to send an MSS greater
  303.           than the maximum MTU of the connected networks, and we
  304.           recommend that hosts do not use 65495.  It is quite possible
  305.           that some IP implementations have sign-bit bugs that would be
  306.           tickled by unnecessary use of such a large MSS.
  307.  
  308.  
  309. 4. Router specification
  310.  
  311.    When a router is unable to forward a datagram because it exceeds the
  312.    MTU of the next-hop network and its Don't Fragment bit is set, the
  313.    router is required to return an ICMP Destination Unreachable message
  314.    to the source of the datagram, with the Code indicating
  315.    "fragmentation needed and DF set".  To support the Path MTU Discovery
  316.    technique specified in this memo, the router MUST include the MTU of
  317.    that next-hop network in the low-order 16 bits of the ICMP header
  318.    field that is labelled "unused" in the ICMP specification [7].  The
  319.    high-order 16 bits remain unused, and MUST be set to zero.  Thus, the
  320.    message has the following format:
  321.  
  322.        0                   1                   2                   3
  323.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  324.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  325.       |   Type = 3    |   Code = 4    |           Checksum            |
  326.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  327.       |           unused = 0          |         Next-Hop MTU          |
  328.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  329.       |      Internet Header + 64 bits of Original Datagram Data      |
  330.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  331.  
  332.  
  333.    The value carried in the Next-Hop MTU field is:
  334.  
  335.           The size in octets of the largest datagram that could be
  336.           forwarded, along the path of the original datagram, without
  337.           being fragmented at this router.  The size includes the IP
  338.           header and IP data, and does not include any lower-level
  339.           headers.
  340.  
  341.  
  342. Mogul & Deering                                                 [page 6]
  343.  
  344.  
  345. RFC 1191                   Path MTU Discovery              November 1990
  346.  
  347.  
  348.  
  349.  
  350.    This field will never contain a value less than 68, since every
  351.    router "must be able to forward a datagram of 68 octets without
  352.    fragmentation" [8].
  353.  
  354.  
  355. 5. Host processing of old-style messages
  356.  
  357.    In this section we outline several possible strategies for a host to
  358.    follow upon receiving a Datagram Too Big message from an unmodified
  359.    router (i.e., one where the Next-Hop MTU field is zero).  This
  360.    section is not part of the protocol specification.
  361.  
  362.    The simplest thing for a host to do in response to such a message is
  363.    to assume that the PMTU is the minimum of its currently-assumed PMTU
  364.    and 576, and to stop setting the DF bit in datagrams sent on that
  365.    path.  Thus, the host falls back to the same PMTU as it would choose
  366.    under current practice (see section 3.3.3 of "Requirements for
  367.    Internet Hosts -- Communication Layers" [1]).  This strategy has the
  368.    advantage that it terminates quickly, and does no worse than existing
  369.    practice.  It fails, however, to avoid fragmentation in some cases,
  370.    and to make the most efficient utilization of the internetwork in
  371.    other cases.
  372.  
  373.    More sophisticated strategies involve "searching" for an accurate
  374.    PMTU estimate, by continuing to send datagrams with the DF bit while
  375.    varying their sizes.  A good search strategy is one that obtains an
  376.    accurate estimate of the Path MTU without causing many packets to be
  377.    lost in the process.
  378.  
  379.    Several possible strategies apply algorithmic functions to the
  380.    previous PMTU estimate to generate a new estimate.  For example, one
  381.    could multiply the old estimate by a constant (say, 0.75).  We do NOT
  382.    recommend this; it either converges far too slowly, or it
  383.    substantially underestimates the true PMTU.
  384.  
  385.    A more sophisticated approach is to do a binary search on the packet
  386.    size.  This converges somewhat faster, although it still takes 4 or 5
  387.    steps to converge from an FDDI MTU to an Ethernet MTU.  A serious
  388.    disadvantage is that it requires a complex implementation in order to
  389.    recognize when a datagram has made it to the other end (indicating
  390.    that the current estimate is too low).  We also do not recommend this
  391.    strategy.
  392.  
  393.    One strategy that appears to work quite well starts from the
  394.    observation that there are, in practice, relatively few MTU values in
  395.    use in the Internet.  Thus, rather than blindly searching through
  396.    arbitrarily chosen values, we can search only the ones that are
  397.  
  398.  
  399. Mogul & Deering                                                 [page 7]
  400.  
  401.  
  402. RFC 1191                   Path MTU Discovery              November 1990
  403.  
  404.  
  405.  
  406.  
  407.    likely to appear.  Moreover, since designers tend to chose MTUs in
  408.    similar ways, it is possible to collect groups of similar MTU values
  409.    and use the lowest value in the group as our search "plateau".  (It
  410.    is clearly better to underestimate an MTU by a few per cent than to
  411.    overestimate it by one octet.)
  412.  
  413.    In section 7, we describe how we arrived at a table of representative
  414.    MTU plateaus for use in PMTU estimation.  With this table,
  415.    convergence is as good as binary search in the worst case, and is far
  416.    better in common cases (for example, it takes only two round-trip
  417.    times to go from an FDDI MTU to an Ethernet MTU).  Since the plateaus
  418.    lie near powers of two, if an MTU is not represented in this table,
  419.    the algorithm will not underestimate it by more than a factor of 2.
  420.  
  421.    Any search strategy must have some "memory" of previous estimates in
  422.    order to chose the next one.  One approach is to use the
  423.    currently-cached estimate of the Path MTU, but in fact there is
  424.    better information available in the Datagram Too Big message itself.
  425.    All ICMP Destination Unreachable messages, including this one,
  426.    contain the IP header of the original datagram, which contains the
  427.    Total Length of the datagram that was too big to be forwarded without
  428.    fragmentation.  Since this Total Length may be less than the current
  429.    PMTU estimate, but is nonetheless larger than the actual PMTU, it may
  430.    be a good input to the method for choosing the next PMTU estimate.
  431.  
  432.           Note: routers based on implementations derived from 4.2BSD
  433.           Unix send an incorrect value for the Total Length of the
  434.           original IP datagram.  The value sent by these routers is the
  435.           sum of the original Total Length and the original Header
  436.           Length (expressed in octets).  Since it is impossible for the
  437.           host receiving such a Datagram Too Big message to know if it
  438.           sent by one of these routers, the host must be conservative
  439.           and assume that it is.  If the Total Length field returned is
  440.           not less than the current PMTU estimate, it must be reduced by
  441.           4 times the value of the returned Header Length field.
  442.  
  443.    The strategy we recommend, then, is to use as the next PMTU estimate
  444.    the greatest plateau value that is less than the returned Total
  445.    Length field (corrected, if necessary, according to the Note above).
  446.  
  447.  
  448. 6. Host implementation
  449.  
  450.    In this section we discuss how PMTU Discovery is implemented in host
  451.    software.  This is not a specification, but rather a set of
  452.    suggestions.
  453.  
  454.    The issues include:
  455.  
  456. Mogul & Deering                                                 [page 8]
  457.  
  458.  
  459. RFC 1191                   Path MTU Discovery              November 1990
  460.  
  461.  
  462.  
  463.  
  464.       - What layer or layers implement PMTU Discovery?
  465.  
  466.       - Where is the PMTU information cached?
  467.  
  468.       - How is stale PMTU information removed?
  469.  
  470.       - What must transport and higher layers do?
  471.  
  472.  
  473. 6.1. Layering
  474.  
  475.    In the IP architecture, the choice of what size datagram to send is
  476.    made by a protocol at a layer above IP.  We refer to such a protocol
  477.    as a "packetization protocol".  Packetization protocols are usually
  478.    transport protocols (for example, TCP) but can also be higher-layer
  479.    protocols (for example, protocols built on top of UDP).
  480.  
  481.    Implementing PMTU Discovery in the packetization layers simplifies
  482.    some of the inter-layer issues, but has several drawbacks: the
  483.    implementation may have to be redone for each packetization protocol,
  484.    it becomes hard to share PMTU information between different
  485.    packetization layers, and the connection-oriented state maintained by
  486.    some packetization layers may not easily extend to save PMTU
  487.    information for long periods.
  488.  
  489.    We therefore believe that the IP layer should store PMTU information
  490.    and that the ICMP layer should process received Datagram Too Big
  491.    messages.  The packetization layers must still be able to respond to
  492.    changes in the Path MTU, by changing the size of the datagrams they
  493.    send, and must also be able to specify that datagrams are sent with
  494.    the DF bit set.  We do not want the IP layer to simply set the DF bit
  495.    in every packet, since it is possible that a packetization layer,
  496.    perhaps a UDP application outside the kernel, is unable to change its
  497.    datagram size.  Protocols involving intentional fragmentation, while
  498.    inelegant, are sometimes successful (NFS being the primary example),
  499.    and we do not want to break such protocols.
  500.  
  501.    To support this layering, packetization layers require an extension
  502.    of the IP service interface defined in [1]:
  503.  
  504.           A way to learn of changes in the value of MMS_S, the "maximum
  505.           send transport-message size", which is derived from the Path
  506.           MTU by subtracting the minimum IP header size.
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513. Mogul & Deering                                                 [page 9]
  514.  
  515.  
  516. RFC 1191                   Path MTU Discovery              November 1990
  517.  
  518.  
  519.  
  520.  
  521. 6.2. Storing PMTU information
  522.  
  523.    In general, the IP layer should associate each PMTU value that it has
  524.    learned with a specific path.  A path is identified by a source
  525.    address, a destination address and an IP type-of-service.  (Some
  526.    implementations do not record the source address of paths; this is
  527.    acceptable for single-homed hosts, which have only one possible
  528.    source address.)
  529.  
  530.           Note: Some paths may be further distinguished by different
  531.           security classifications.  The details of such classifications
  532.           are beyond the scope of this memo.
  533.  
  534.    The obvious place to store this association is as a field in the
  535.    routing table entries.  A host will not have a route for every
  536.    possible destination, but it should be able to cache a per-host route
  537.    for every active destination.  (This requirement is already imposed
  538.    by the need to process ICMP Redirect messages.)
  539.  
  540.    When the first packet is sent to a host for which no per-host route
  541.    exists, a route is chosen either from the set of per-network routes,
  542.    or from the set of default routes.  The PMTU fields in these route
  543.    entries should be initialized to be the MTU of the associated
  544.    first-hop data link, and must never be changed by the PMTU Discovery
  545.    process.  (PMTU Discovery only creates or changes entries for
  546.    per-host routes).  Until a Datagram Too Big message is received, the
  547.    PMTU associated with the initially-chosen route is presumed to be
  548.    accurate.
  549.  
  550.    When a Datagram Too Big message is received, the ICMP layer
  551.    determines a new estimate for the Path MTU (either from a non-zero
  552.    Next-Hop MTU value in the packet, or using the method described in
  553.    section 5).  If a per-host route for this path does not exist, then
  554.    one is created (almost as if a per-host ICMP Redirect is being
  555.    processed; the new route uses the same first-hop router as the
  556.    current route).  If the PMTU estimate associated with the per-host
  557.    route is higher than the new estimate, then the value in the routing
  558.    entry is changed.
  559.  
  560.    The packetization layers must be notified about decreases in the
  561.    PMTU.  Any packetization layer instance (for example, a TCP
  562.    connection) that is actively using the path must be notified if the
  563.    PMTU estimate is decreased.
  564.  
  565.           Note: even if the Datagram Too Big message contains an
  566.           Original Datagram Header that refers to a UDP packet, the TCP
  567.           layer must be notified if any of its connections use the given
  568.  
  569.  
  570. Mogul & Deering                                                [page 10]
  571.  
  572.  
  573. RFC 1191                   Path MTU Discovery              November 1990
  574.  
  575.  
  576.  
  577.  
  578.           path.
  579.  
  580.    Also, the instance that sent the datagram that elicited the Datagram
  581.    Too Big message should be notified that its datagram has been
  582.    dropped, even if the PMTU estimate has not changed, so that it may
  583.    retransmit the dropped datagram.
  584.  
  585.           Note: The notification mechanism can be analogous to the
  586.           mechanism used to provide notification of an ICMP Source
  587.           Quench message.  In some implementations (such as
  588.           4.2BSD-derived systems), the existing notification mechanism
  589.           is not able to identify the specific connection involved, and
  590.           so an additional mechanism is necessary.
  591.  
  592.           Alternatively, an implementation can avoid the use of an
  593.           asynchronous notification mechanism for PMTU decreases by
  594.           postponing notification until the next attempt to send a
  595.           datagram larger than the PMTU estimate.  In this approach,
  596.           when an attempt is made to SEND a datagram with the DF bit
  597.           set, and the datagram is larger than the PMTU estimate, the
  598.           SEND function should fail and return a suitable error
  599.           indication.  This approach may be more suitable to a
  600.           connectionless packetization layer (such as one using UDP),
  601.           which (in some implementations) may be hard to "notify" from
  602.           the ICMP layer.  In this case, the normal timeout-based
  603.           retransmission mechanisms would be used to recover from the
  604.           dropped datagrams.
  605.  
  606.    It is important to understand that the notification of the
  607.    packetization layer instances using the path about the change in the
  608.    PMTU is distinct from the notification of a specific instance that a
  609.    packet has been dropped.  The latter should be done as soon as
  610.    practical (i.e., asynchronously from the point of view of the
  611.    packetization layer instance), while the former may be delayed until
  612.    a packetization layer instance wants to create a packet.
  613.    Retransmission should be done for only for those packets that are
  614.    known to be dropped, as indicated by a Datagram Too Big message.
  615.  
  616.  
  617. 6.3. Purging stale PMTU information
  618.  
  619.    Internetwork topology is dynamic; routes change over time.  The PMTU
  620.    discovered for a given destination may be wrong if a new route comes
  621.    into use.  Thus, PMTU information cached by a host can become stale.
  622.  
  623.    Because a host using PMTU Discovery always sets the DF bit, if the
  624.    stale PMTU value is too large, this will be discovered almost
  625.  
  626.  
  627. Mogul & Deering                                                [page 11]
  628.  
  629.  
  630. RFC 1191                   Path MTU Discovery              November 1990
  631.  
  632.  
  633.  
  634.  
  635.    immediately once a datagram is sent to the given destination.  No
  636.    such mechanism exists for realizing that a stale PMTU value is too
  637.    small, so an implementation should "age" cached values.  When a PMTU
  638.    value has not been decreased for a while (on the order of 10
  639.    minutes), the PMTU estimate should be set to the first-hop data-link
  640.    MTU, and the packetization layers should be notified of the change.
  641.    This will cause the complete PMTU Discovery process to take place
  642.    again.
  643.  
  644.           Note: an implementation should provide a means for changing
  645.           the timeout duration, including setting it to "infinity".  For
  646.           example, hosts attached to an FDDI network which is then
  647.           attached to the rest of the Internet via a slow serial line
  648.           are never going to discover a new non-local PMTU, so they
  649.           should not have to put up with dropped datagrams every 10
  650.           minutes.
  651.  
  652.    An upper layer MUST not retransmit datagrams in response to an
  653.    increase in the PMTU estimate, since this increase never comes in
  654.    response to an indication of a dropped datagram.
  655.  
  656.    One approach to implementing PMTU aging is to add a timestamp field
  657.    to the routing table entry.  This field is initialized to a
  658.    "reserved" value, indicating that the PMTU has never been changed.
  659.    Whenever the PMTU is decreased in response to a Datagram Too Big
  660.    message, the timestamp is set to the current time.
  661.  
  662.    Once a minute, a timer-driven procedure runs through the routing
  663.    table, and for each entry whose timestamp is not "reserved" and is
  664.    older than the timeout interval:
  665.  
  666.       - The PMTU estimate is set to the MTU of the associated first
  667.         hop.
  668.  
  669.       - Packetization layers using this route are notified of the
  670.         increase.
  671.  
  672.    PMTU estimates may disappear from the routing table if the per-host
  673.    routes are removed; this can happen in response to an ICMP Redirect
  674.    message, or because certain routing-table daemons delete old routes
  675.    after several minutes.  Also, on a multi-homed host a topology change
  676.    may result in the use of a different source interface.  When this
  677.    happens, if the packetization layer is not notified then it may
  678.    continue to use a cached PMTU value that is now too small.  One
  679.    solution is to notify the packetization layer of a possible PMTU
  680.    change whenever a Redirect message causes a route change, and
  681.    whenever a route is simply deleted from the routing table.
  682.  
  683.  
  684. Mogul & Deering                                                [page 12]
  685.  
  686.  
  687. RFC 1191                   Path MTU Discovery              November 1990
  688.  
  689.  
  690.  
  691.  
  692.           Note: a more sophisticated method for detecting PMTU increases
  693.           is described in section 7.1.
  694.  
  695.  
  696. 6.4. TCP layer actions
  697.  
  698.    The TCP layer must track the PMTU for the destination of a
  699.    connection; it should not send datagrams that would be larger than
  700.    this.  A simple implementation could ask the IP layer for this value
  701.    (using the GET_MAXSIZES interface described in [1]) each time it
  702.    created a new segment, but this could be inefficient.  Moreover, TCP
  703.    implementations that follow the "slow-start" congestion-avoidance
  704.    algorithm [4] typically calculate and cache several other values
  705.    derived from the PMTU.  It may be simpler to receive asynchronous
  706.    notification when the PMTU changes, so that these variables may be
  707.    updated.
  708.  
  709.    A TCP implementation must also store the MSS value received from its
  710.    peer (which defaults to 536), and not send any segment larger than
  711.    this MSS, regardless of the PMTU.  In 4.xBSD-derived implementations,
  712.    this requires adding an additional field to the TCP state record.
  713.  
  714.    Finally, when a Datagram Too Big message is received, it implies that
  715.    a datagram was dropped by the router that sent the ICMP message.  It
  716.    is sufficient to treat this as any other dropped segment, and wait
  717.    until the retransmission timer expires to cause retransmission of the
  718.    segment.  If the PMTU Discovery process requires several steps to
  719.    estimate the right PMTU, this could delay the connection by many
  720.    round-trip times.
  721.  
  722.    Alternatively, the retransmission could be done in immediate response
  723.    to a notification that the Path MTU has changed, but only for the
  724.    specific connection specified by the Datagram Too Big message.  The
  725.    datagram size used in the retransmission should, of course, be no
  726.    larger than the new PMTU.
  727.  
  728.           Note: One MUST not retransmit in response to every Datagram
  729.           Too Big message, since a burst of several oversized segments
  730.           will give rise to several such messages and hence several
  731.           retransmissions of the same data.  If the new estimated PMTU
  732.           is still wrong, the process repeats, and there is an
  733.           exponential growth in the number of superfluous segments sent!
  734.  
  735.           This means that the TCP layer must be able to recognize when a
  736.           Datagram Too Big notification actually decreases the PMTU that
  737.           it has already used to send a datagram on the given
  738.           connection, and should ignore any other notifications.
  739.  
  740.  
  741. Mogul & Deering                                                [page 13]
  742.  
  743.  
  744. RFC 1191                   Path MTU Discovery              November 1990
  745.  
  746.  
  747.  
  748.  
  749.    Modern TCP implementations incorporate "congestion advoidance" and
  750.    "slow-start" algorithms to improve performance [4].  Unlike a
  751.    retransmission caused by a TCP retransmission timeout, a
  752.    retransmission caused by a Datagram Too Big message should not change
  753.    the congestion window.  It should, however, trigger the slow-start
  754.    mechanism (i.e., only one segment should be retransmitted until
  755.    acknowledgements begin to arrive again).
  756.  
  757.    TCP performance can be reduced if the sender's maximum window size is
  758.    not an exact multiple of the segment size in use (this is not the
  759.    congestion window size, which is always a multiple of the segment
  760.    size).  In many system (such as those derived from 4.2BSD), the
  761.    segment size is often set to 1024 octets, and the maximum window size
  762.    (the "send space") is usually a multiple of 1024 octets, so the
  763.    proper relationship holds by default.  If PMTU Discovery is used,
  764.    however, the segment size may not be a submultiple of the send space,
  765.    and it may change during a connection; this means that the TCP layer
  766.    may need to change the transmission window size when PMTU Discovery
  767.    changes the PMTU value.  The maximum window size should be set to the
  768.    greatest multiple of the segment size (PMTU - 40) that is less than
  769.    or equal to the sender's buffer space size.
  770.  
  771.    PMTU Discovery does not affect the value sent in the TCP MSS option,
  772.    because that value is used by the other end of the connection, which
  773.    may be using an unrelated PMTU value.
  774.  
  775.  
  776. 6.5. Issues for other transport protocols
  777.  
  778.    Some transport protocols (such as ISO TP4 [3]) are not allowed to
  779.    repacketize when doing a retransmission.  That is, once an attempt is
  780.    made to transmit a datagram of a certain size, its contents cannot be
  781.    split into smaller datagrams for retransmission.  In such a case, the
  782.    original datagram should be retransmitted without the DF bit set,
  783.    allowing it to be fragmented as necessary to reach its destination.
  784.    Subsequent datagrams, when transmitted for the first time, should be
  785.    no larger than allowed by the Path MTU, and should have the DF bit
  786.    set.
  787.  
  788.    The Sun Network File System (NFS) uses a Remote Procedure Call (RPC)
  789.    protocol [11] that, in many cases, sends datagrams that must be
  790.    fragmented even for the first-hop link.  This might improve
  791.    performance in certain cases, but it is known to cause reliability
  792.    and performance problems, especially when the client and server are
  793.    separated by routers.
  794.  
  795.    We recommend that NFS implementations use PMTU Discovery whenever
  796.  
  797.  
  798. Mogul & Deering                                                [page 14]
  799.  
  800.  
  801. RFC 1191                   Path MTU Discovery              November 1990
  802.  
  803.  
  804.  
  805.  
  806.    routers are involved.  Most NFS implementations allow the RPC
  807.    datagram size to be changed at mount-time (indirectly, by changing
  808.    the effective file system block size), but might require some
  809.    modification to support changes later on.
  810.  
  811.    Also, since a single NFS operation cannot be split across several UDP
  812.    datagrams, certain operations (primarily, those operating on file
  813.    names and directories) require a minimum datagram size that may be
  814.    larger than the PMTU.  NFS implementations should not reduce the
  815.    datagram size below this threshold, even if PMTU Discovery suggests a
  816.    lower value.  (Of course, in this case datagrams should not be sent
  817.    with DF set.)
  818.  
  819.  
  820. 6.6. Management interface
  821.  
  822.    We suggest that an implementation provide a way for a system utility
  823.    program to:
  824.  
  825.       - Specify that PMTU Discovery not be done on a given route.
  826.  
  827.       - Change the PMTU value associated with a given route.
  828.  
  829.    The former can be accomplished by associating a flag with the routing
  830.    entry; when a packet is sent via a route with this flag set, the IP
  831.    layer leaves the DF bit clear no matter what the upper layer
  832.    requests.
  833.  
  834.    These features might be used to work around an anomalous situation,
  835.    or by a routing protocol implementation that is able to obtain Path
  836.    MTU values.
  837.  
  838.    The implementation should also provide a way to change the timeout
  839.    period for aging stale PMTU information.
  840.  
  841.  
  842. 7. Likely values for Path MTUs
  843.  
  844.    The algorithm recommended in section 5 for "searching" the space of
  845.    Path MTUs is based on a table of values that severely restricts the
  846.    search space.  We describe here a table of MTU values that, as of
  847.    this writing, represents all major data-link technologies in use in
  848.    the Internet.
  849.  
  850.    In table 7-1, data links are listed in order of decreasing MTU, and
  851.    grouped so that each set of similar MTUs is associated with a
  852.    "plateau" equal to the lowest MTU in the group.  (The table also
  853.  
  854.  
  855. Mogul & Deering                                                [page 15]
  856.  
  857.  
  858. RFC 1191                   Path MTU Discovery              November 1990
  859.  
  860.  
  861.  
  862.  
  863.    includes some entries not currently associated with a data link, and
  864.    gives references where available).  Where a plateau represents more
  865.    than one MTU, the table shows the maximum inaccuracy associated with
  866.    the plateau, as a percentage.
  867.  
  868.    We do not expect that the values in the table, especially for higher
  869.    MTU levels, are going to be valid forever.  The values given here are
  870.    an implementation suggestion, NOT a specification or requirement.
  871.    Implementors should use up-to-date references to pick a set of
  872.    plateaus; it is important that the table not contain too many entries
  873.    or the process of searching for a PMTU might waste Internet
  874.    resources.  Implementors should also make it convenient for customers
  875.    without source code to update the table values in their systems (for
  876.    example, the table in a BSD-derived Unix kernel could be changed
  877.    using a new "ioctl" command).
  878.  
  879.           Note: It might be a good idea to add a few table entries for
  880.           values equal to small powers of 2 plus 40 (for the IP and TCP
  881.           headers), where no similar values exist, since this seems to
  882.           be a reasonably non-arbitrary way of choosing arbitrary
  883.           values.
  884.  
  885.           The table might also contain entries for values slightly less
  886.           than large powers of 2, in case MTUs are defined near those
  887.           values (it is better in this case for the table entries to be
  888.           low than to be high, or else the next lowest plateau may be
  889.           chosen instead).
  890.  
  891.  
  892. 7.1. A better way to detect PMTU increases
  893.  
  894.    Section 6.3 suggests detecting increases in the PMTU value by
  895.    periodically increasing the PTMU estimate to the first-hop MTU.
  896.    Since it is likely that this process will simply "rediscover" the
  897.    current PTMU estimate, at the cost of several dropped datagrams, it
  898.    should not be done often.
  899.  
  900.    A better approach is to periodically increase the PMTU estimate to
  901.    the next-highest value in the plateau table (or the first-hop MTU, if
  902.    that is smaller).  If the increased estimate is wrong, at most one
  903.    round-trip time is wasted before the correct value is rediscovered.
  904.    If the increased estimate is still too low, a higher estimate will be
  905.    attempted somewhat later.
  906.  
  907.    Because it may take several such periods to discover a significant
  908.    increase in the PMTU, we recommend that a short timeout period should
  909.    be used after the estimate is increased, and a longer timeout be used
  910.  
  911.  
  912. Mogul & Deering                                                [page 16]
  913.  
  914.  
  915. RFC 1191                   Path MTU Discovery              November 1990
  916.  
  917.  
  918.  
  919.  
  920.    Plateau    MTU    Comments                      Reference
  921.    ------     ---    --------                      ---------
  922.               65535  Official maximum MTU          RFC 791
  923.               65535  Hyperchannel                  RFC 1044
  924.    65535
  925.    32000             Just in case
  926.               17914  16Mb IBM Token Ring           ref. [6]
  927.    17914
  928.               8166   IEEE 802.4                    RFC 1042
  929.    8166
  930.               4464   IEEE 802.5 (4Mb max)          RFC 1042
  931.               4352   FDDI (Revised)                RFC 1188
  932.    4352 (1%)
  933.               2048   Wideband Network              RFC 907
  934.               2002   IEEE 802.5 (4Mb recommended)  RFC 1042
  935.    2002 (2%)
  936.               1536   Exp. Ethernet Nets            RFC 895
  937.               1500   Ethernet Networks             RFC 894
  938.               1500   Point-to-Point (default)      RFC 1134
  939.               1492   IEEE 802.3                    RFC 1042
  940.    1492 (3%)
  941.               1006   SLIP                          RFC 1055
  942.               1006   ARPANET                       BBN 1822
  943.    1006
  944.               576    X.25 Networks                 RFC 877
  945.               544    DEC IP Portal                 ref. [10]
  946.               512    NETBIOS                       RFC 1088
  947.               508    IEEE 802/Source-Rt Bridge     RFC 1042
  948.               508    ARCNET                        RFC 1051
  949.    508 (13%)
  950.               296    Point-to-Point (low delay)    RFC 1144
  951.    296
  952.    68                Official minimum MTU          RFC 791
  953.  
  954.                 Table 7-1:  Common MTUs in the Internet
  955.  
  956.    after the PTMU estimate is decreased because of a Datagram Too Big
  957.    message.  For example, after the PTMU estimate is decreased, the
  958.    timeout should be set to 10 minutes; once this timer expires and a
  959.    larger MTU is attempted, the timeout can be set to a much smaller
  960.    value (say, 2 minutes).  In no case should the timeout be shorter
  961.    than the estimated round-trip time, if this is known.
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968.  
  969. Mogul & Deering                                                [page 17]
  970.  
  971.  
  972. RFC 1191                   Path MTU Discovery              November 1990
  973.  
  974.  
  975.  
  976.  
  977. 8. Security considerations
  978.  
  979.    This Path MTU Discovery mechanism makes possible two denial-of-
  980.    service attacks, both based on a malicious party sending false
  981.    Datagram Too Big messages to an Internet host.
  982.  
  983.    In the first attack, the false message indicates a PMTU much smaller
  984.    than reality.  This should not entirely stop data flow, since the
  985.    victim host should never set its PMTU estimate below the absolute
  986.    minimum, but at 8 octets of IP data per datagram, progress could be
  987.    slow.
  988.  
  989.    In the other attack, the false message indicates a PMTU greater than
  990.    reality.  If believed, this could cause temporary blockage as the
  991.    victim sends datagrams that will be dropped by some router.  Within
  992.    one round-trip time, the host would discover its mistake (receiving
  993.    Datagram Too Big messages from that router), but frequent repetition
  994.    of this attack could cause lots of datagrams to be dropped.  A host,
  995.    however, should never raise its estimate of the PMTU based on a
  996.    Datagram Too Big message, so should not be vulnerable to this attack.
  997.  
  998.    A malicious party could also cause problems if it could stop a victim
  999.    from receiving legitimate Datagram Too Big messages, but in this case
  1000.    there are simpler denial-of-service attacks available.
  1001.  
  1002.  
  1003. References
  1004.  
  1005. [1]   R. Braden, ed.  Requirements for Internet Hosts -- Communication
  1006.       Layers.  RFC 1122, SRI Network Information Center, October, 1989.
  1007.  
  1008. [2]   Geof Cooper.  IP Datagram Sizes.  Electronic distribution of the
  1009.       TCP-IP Discussion Group, Message-ID
  1010.       <8705240517.AA01407@apolling.imagen.uucp>.
  1011.  
  1012. [3]   ISO.  ISO Transport Protocol Specification: ISO DP 8073.  RFC 905,
  1013.       SRI Network Information Center, April, 1984.
  1014.  
  1015. [4]   Van Jacobson.  Congestion Avoidance and Control.  In Proc. SIGCOMM
  1016.       '88 Symposium on Communications Architectures and Protocols, pages
  1017.       314-329.  Stanford, CA, August, 1988.
  1018.  
  1019. [5]   C. Kent and J. Mogul.  Fragmentation Considered Harmful.  In Proc.
  1020.       SIGCOMM '87 Workshop on Frontiers in Computer Communications
  1021.       Technology.  August, 1987.
  1022.  
  1023. [6]   Drew Daniel Perkins.  Private Communication.
  1024.  
  1025.  
  1026. Mogul & Deering                                                [page 18]
  1027.  
  1028.  
  1029. RFC 1191                   Path MTU Discovery              November 1990
  1030.  
  1031.  
  1032.  
  1033.  
  1034. [7]   J. Postel.  Internet Control Message Protocol.  RFC 792, SRI
  1035.       Network Information Center, September, 1981.
  1036.  
  1037. [8]   J. Postel.  Internet Protocol.  RFC 791, SRI Network Information
  1038.       Center, September, 1981.
  1039.  
  1040. [9]   J. Postel.  The TCP Maximum Segment Size and Related Topics.  RFC
  1041.       879, SRI Network Information Center, November, 1983.
  1042.  
  1043. [10]  Michael Reilly.  Private Communication.
  1044.  
  1045. [11]  Sun Microsystems, Inc.  RPC: Remote Procedure Call Protocol.  RFC
  1046.       1057, SRI Network Information Center, June, 1988.
  1047.  
  1048.  
  1049.  
  1050. Authors' Addresses
  1051.  
  1052.    Jeffrey Mogul
  1053.    Digital Equipment Corporation Western Research Laboratory
  1054.    100 Hamilton Avenue
  1055.    Palo Alto, CA  94301
  1056.  
  1057.    Phone: (415) 853-6643
  1058.    EMail: mogul@decwrl.dec.com
  1059.  
  1060.  
  1061.    Steve Deering
  1062.    Xerox Palo Alto Research Center
  1063.    3333 Coyote Hill Road
  1064.    Palo Alto, CA  94304
  1065.  
  1066.    Phone: (415) 494-4839
  1067.    EMail: deering@xerox.com
  1068.  
  1069.  
  1070.  
  1071.  
  1072.  
  1073.  
  1074.  
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083. Mogul & Deering                                                [page 19]
  1084.